Using packet transfer for driving lcd panel driver electronics

ABSTRACT

In a digital display device, a packet based method of driving selected pixel elements by way of associated data latches included in a column driver is disclosed. For each frame lines in a video frame, a number of video data packets are provided directly to the column driver at a link rate and each of the number of data latches are populated with appropriate video data based upon video data packets within a line period τ. Selected pixel elements are driven based upon the video data.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and takes priority under 35 U.S.C. 120 from U.S. patent application Ser. No. 10/909,103 filed Jul. 29, 2004, which took priority under 35 U.S.C. 119(e) to (i) U.S. Provisional Patent Application No. 60/504,060 (Attorney Docket No. GENSP013P2) filed on Sep. 18, 2003, entitled “DIGITAL/ANALOG VIDEO INTERCONNECT AND METHODS OF USE THEREOF” by Kobayashi, and (ii) U.S. Provisional Patent Application No. 60/563,120 (Attorney Docket No. GENSP112P) filed on Apr. 15, 2004, entitled “USING PACKET TRANSFER FOR DRIVING LCD PANEL DRIVER ELECTRONICS” by Kobayashi, each of which are hereby incorporated by reference herein in their entirety.

BACKGROUND

1. Field of the Invention

The invention relates to display devices. More specifically, the invention describes a method and apparatus for using driving LCD panel drive electronics.

2. Overview

Liquid Crystal Displays (LCDs) have begun to supersede Cathode Ray Tube (CRT) based monitors in the monitor and television applications markets due in part to the fact that LCDs have several advantages compared to CRT based technology. These advantages include smaller size (60% less than comparable CRTs), lower power consumption (50%), lighter weight (70% less than CRT), no electromagnetic fields, and longer service life.

FIG. 1 is a block diagram showing an example of a conventional active matrix liquid crystal display device 100 that includes a liquid crystal display panel 102, a data (or a column) driver 104 that includes a number of data latches 106-1 through 106-n suitable for storing image data, a gate driver 108 that includes gate driver logic circuits 110, a timing controller unit (also referred to as a TCON) 112, and a memory 114 suitable for storing image data included in or coupled to the TCON 112. In some cases, the memory 114 takes the form of a frame memory capable of storing an entire video frame or in other cases, the memory 114 takes the form of a line buffer capable of storing a single line of video data. In either case, the image data is stored in the memory 114 in such a way as to be available to be transferred to the latches 106 one frame line at a time within a period of time referred to as a line period τ. As shown, a pixel clock generator unit 116 also included in or coupled to the TCON 112 is used to convert video data delivered at a link clock rate to the required pixel clock rate.

Typically, the TCON 112 is connected to a video source 128 (such as a personal computer, TV or other such device) suitably arranged to output a video signal (and, in most cases, an associated audio signal). During operation, the TCON 112 sends video data one pixel at a time by way of a multidrop bus 130 to be stored in a correspondingly enabled one of the data latches 106. For example, if the display panel has 1024 pixels per line then there are 1024 latches per line (it should be noted that in the case of a full color display, each pixel is formed of 3 subpixels, Red, Green, and Blue and therefore there are a total of 1024×3=3072 data latches) each of which is connected to the multidrop data bus 130. When the TCON 112 is loading the video data, a first latch receives a latch enable signal and stores the appropriate pixel data, after which a second latch receives the latch enable signal and stores the appropriate pixel data and so on until all 3072 latches have been enabled and stored the appropriate pixel data one at a time. In this way, for each frame line, the TCON 112 must send the all pixel data to the appropriate one of the 3072 data latches within the line period τ. Once all the video data for a particular frame line has been received and latched, the video data is then available to drive selected ones of a number of picture elements 118 included in the LCD array 102 used to form the displayed image.

Therefore, in order for the TCON 112 to provide the correct pixel data to the correct data latch, the TCON 112 must provide a handshake enable signal between each data latch 106 that must propagate from the leftmost data latch 106-1 to the rightmost data latch 106-n in such a way that all video data for a particular frame line is stored with the line period τ. Since even the rightmost data latch 106-n must be driven by the TCON 112, the number of pixels per line is limited by the ability of the TCON 112 to adequately drive the rightmost (and therefore most distant) data latch 106-n. The large number of components (3072 in the case of an 1024 RGB display) coupled to the large multidrop bus 130 presents a severe challenge to the TCON 112 to preserve signal integrity. Since signal integrity is crucial to the proper operation of the display 100, the data rate is typically reduced thereby severely limiting the resolution of the display 100 since all data for a single frame line must be transferred to all data latches 106 within a single line period τ which is typically about 20 microseconds.

One approach to solving this problem is to increase the size of the multidrop bus 130 that unfortunately also increases the line capacitance making it difficult to optimize the transmission of the data on the bus. Other approaches (such as reduced swing differential signaling or RSDS) use multiple busses with 2 pixels per clock instead of a single multidrop bus and a single pixel per clock. Although this approach reduces the drive capability required for the TCON 112, it has the unfortunate result of substantially increasing the complexity of the TCON driving circuitry (as well as doubling the number of pins). For example, in the case of 24 bit color, the RSDS approach would require 24 transmission lines in addition to a dedicated clock line greatly increasing the complexity of the LCD column driver 104.

Therefore a high speed, high bandwidth approach to driving an digital display is needed.

SUMMARY OF THE INVENTION

What is provided is a display architecture embodied as a method, apparatus, and system suitable for implementation with digital displays, such as liquid crystal displays (LCDs), that is independent of pixel rate and provides a high speed, high bandwidth digital display platform.

In a digital display device, a packet based method of driving selected pixel elements by way of associated data latches included in a column driver is disclosed. For each frame lines in a video frame, a number of video data packets are provided directly to the column driver at a link rate and each of the number of data latches are populated with appropriate video data based upon video data packets within a line period τ. Selected pixel elements are driven based upon the video data.

In another embodiment, a digital display device is disclosed that includes a number of pixel elements, an interface arranged to receive and distribute video data packets at a link rate, and a number of data latches each of which are arranged to receive a distributed video data packet from the interface, store video data associated with the received video data packet, and drive selected ones of the pixel elements based upon stored video data.

In yet another embodiment, computer program product for driving selected pixel elements by way of associated data latches included in a column driver In a packet based digital display device is disclosed. Computer code for providing a number of video data packets directly to the column driver at a link rate, computer code for populating each of the number of data latches with appropriate video data based upon video data packets within a line period τ, computer code for driving selected pixel elements based upon the video data, and computer readable medium for storing the computer code.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing an example of a conventional active matrix liquid crystal display device.

FIG. 2 shows an exemplary digital display system in accordance with an embodiment of the invention.

FIG. 3 shows a representative data packet in accordance with an embodiment of the invention.

FIG. 4 shows a high-level diagram of a data stream for transmission over the link in accordance with an embodiment of the invention.

FIG. 5 shows an embodiment of the invention whereby a digital display unit includes two column drivers, each of which is used to drive pixels in corresponding portions of a partitioned display.

FIG. 6 illustrates another system that can be used to implement the invention.

DETAILED DESCRIPTION OF SELECTED EMBODIMENTS

Reference will now be made in detail to a particular embodiment of the invention an example of which is illustrated in the accompanying drawings. While the invention will be described in conjunction with the particular embodiment, it will be understood that it is not intended to limit the invention to the described embodiment. To the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims.

In order for conventionally configured digital display devices, such as LCD panels, to display images, a timing controller must propagate video data (in the form of pixel data at a pixel clock) from a first (typically a leftmost data latch) to a last (typically a rightmost data latch) in such a way that all video data for a particular frame line is stored with a single line period τ (usually about 20 microseconds). Since even the last data latch must be driven by the timing controller, the number of pixels per line is limited by the ability of the timing controller to adequately drive the rightmost (and therefore most distant) data latch within the specified line period τ. As the resolution of a display increases (3072 data latches in the case of a 1024 RGB display), the ability of the timing controller to adequately drive a multidrop bus coupled thereto becomes progressively more difficult and problematic to preserve signal integrity. Since signal integrity is crucial to the proper operation of the display, the data rate is typically reduced thereby severely limiting the resolution of the display since all data for a single frame line must be transferred to all data latches within a single line period τ which is typically about 20 microseconds.

One approach to solving this problem is to increase the size of the multidrop bus that unfortunately also has the effect of increasing the line capacitance making it difficult to optimize the transmission of the data on the bus. Other approaches (such as Reduced Swing Differential Signaling, or RSDS) use multiple busses with 2 pixels per clock instead of a single multidrop bus and a single pixel per clock. Although this approach reduces the drive requirements for the timing controller, it has the unfortunate result of substantially increasing the complexity of the timing controller driving circuitry (as well as doubling the number of pins). For example, in the case of 24 bit color, the RSDS approach requires that the data bus have at least 24 transmission lines in addition to a dedicated clock line thereby greatly increasing the complexity of the LCD column driver.

Accordingly, a packet based display architecture embodied as a method, apparatus, and system suitable for implementation with digital displays, such as liquid crystal displays (LCDs), that decouples the pixel rate from the line period τ, simplifies the column driver circuitry provides a high speed, high bandwidth digital display platform. The display architecture does away with the large data bus commonly used with conventional digital display architecture in favor of a point to point “daisy chain” configuration. In this configuration, a number of data latches consistent with a native horizontal line resolution of the display are directly connected to each other. In this way, the video data packets are transported and received at a link data rate and not as required in conventional display architectures, at the pixel data rate.

In this way, the complexity of the LCD driver circuitry is greatly simplified since there is no requirement for pixel clock regeneration (such as time based recovery) and the size of the data bus is greatly reduced since the data packets themselves can be encoded to provide necessary timing and other signals heretofore provided by separate data lines in the data bus. In addition, the native line resolution of the display (i.e., the number of horizontal pixels) can be substantially increased without the concomitant increase in driver complexity or bus size since the only constraint is that all necessary video data be latched for a particular frame line within the line period τ.

The invention will now be described in terms of a representative LCD panel. However, it should be noted that any digital fixed pixel display, be it LCD, plasma, DLP based, is also suitable and therefore the use of an LCD panel in the following description should not be considered to limit either the scope or the intent of the invention. It should be noted that the invention is also well suited to be used in conjunction with any packet based video display interface such as described in copending U.S. patent application Ser. No. 10/726,794 entitled “PACKET BASED VIDEO DISPLAY INTERFACE AND METHODS OF USE THEREOF” by Kobayashi filed Dec. 3, 2003 and incorporated herein by reference for all purposes.

Accordingly, FIG. 2 shows an exemplary digital display system 200 in accordance with an embodiment of the invention. The system 200 includes a digital display unit 202 coupled to a video source 204 having a graphics engine 206 by way of a data link 208. It should be noted that the video source 204 can include either or both a digital image (i.e. still or digital video) source and/or an analog image (i.e., still or analog video) source. Accordingly, the video source 204 provides various video signals that can have any number and type of well-known formats, such as composite video, serial digital, parallel digital, RGB, or consumer digital video. The video signal can be an analog video signal provided the source 204 includes some form of an analog video source such as for example, an analog television, still camera, analog VCR, DVD player, camcorder, laser disk player, TV tuner, set top box (with satellite DSS or cable signal) and the like. The source 204 can also include a digital image source such as for example a digital television (DTV), digital still camera, and the like. The digital video signal can be any number and type of well known digital formats such as, SMPTE 274M-1995 (1920×1080 resolution, progressive or interlaced scan), SMPTE 296M-1997 (1280×720 resolution, progressive scan), as well as standard 480 progressive scan video.

The LCD panel 202 includes a number of picture elements 210 (pixels) that are arranged in a matrix connected to a data driver 212 by way of a plurality of data lines 214 and a plurality of gate lines 216. In the described embodiment, these picture elements take the form of a plurality of thin film transistors (TFTs) 218 that are connected between the data lines 214 and the gate lines 216. During operation, each of data latch 220 outputs digital data signals to an associated digital to analog converter (DAC) 222 by way of the data lines 214. Concurrently, each of logic circuit 224 included in a gate driver 226 outputs a predetermined scanning signal to the gate lines 216 in sequence at timings which are in sync with a horizontal synchronizing signal. In this way, the TFTs 218 are turned ON when the predetermined scanning signal is supplied to the gate lines 214 to transmit the analog data signals supplied by the DACs 222 by way of the data lines 214 that ultimately drive selected ones of the picture elements 210.

When the graphics engine 206 includes or is coupled to an analog video source, the graphics engine 206 digitizes the analog data to form digital data that is then packetized into a number of data packets 228. In the described embodiment, each of the data packets are transmitted to the display 202 by way of the link 208 at a transmission rate referred to as a link rate LR that is independent of the native stream rates of the video data. It should be noted, however, that the bandwidth of the link 208 must be greater than the aggregate bandwidth of all data stream(s) being transmitted over the link 208. Regardless of the type of video source or display, however, all video data are digitized (if necessary) and, in most cases, packetized prior to transmission over the link 208. In some cases, however, using a packetizer 230 included in or coupled to a display interface 232, the display unit 202 itself will packetize any video and/or audio data transmitted over the link 208 in an unpacketized form thereby enabling the use of the display 202 with all video sources.

In the described embodiment, the speed, or link rate, of the link 208 can be configured to include a number of logical data channels (not shown) that can be adjusted to compensate for link conditions. For example, at 2.5 Gbps per channel, the link 208 can support SXGA 60 Hz with a color depth of 18 bits per pixel over a single channel. It should be noted that a reduction in the number of channels reduces not only the cost of interconnect, but also reduces the power consumption which is an important consideration (and desirable) for power sensitive applications such as portable devices and the like. However, by increasing the number of channels to four, the link 208 can support WQSXGA (3200×2048 image resolution) with a color depth of 24-bits per pixel at 60 Hz. or QSXGA (2560×2048) with a color depth of 18-bits per pixel at 60 Hz, without data compression. Even at the lowest rate of 1.0 Gbps per channel, only two channels are required to support an uncompressed HDTV (i.e., 1080i or 720p) data stream.

A representative data packet 300 is shown in FIG. 3 includes a data packet header 302 that in one embodiment includes 16 bits where four bits are the Stream ID (SID), a fifth bit is a video frame sequence bit which acts as the least significant bit of the frame counter which toggles from “0” to “1” or from “1” to “0” at the video frame boundary (used only for uncompressed video stream). Sixth and seventh bits are reserved whereas the remaining bits include a 4-bit CRC (CRC) that checks errors for the previous eight bits.

In order to transmit the video data, the video source 204 forms a data stream 234 that includes a number of the data packets 228 which are then received and processed by the display interface 230. In the described embodiment, the data packets 228 are then forwarded to directly to the data latches 220 included in the column driver 212 in such a way that all the video data (in the form of pixel data) used for the display of a particular frame line n of the video frame is provided to the data latches 220 within a line period τ. Therefore, once each data latch 220 has appropriate pixel data stored therein, the data driver 212 drive appropriate ones of the TFTs 218 in the LCD array 202.

FIG. 4 shows a high-level diagram of a data stream 400 for transmission over the link 208 formed of a number of video data packets 402 and audio data packets 404 multiplexed into the single data stream 400. In this example the video data packets 402 are consistent with UXGA graphics 1280×720p video (Stream ID=1) having an associated audio in the form of the audio packets 404 (Stream ID=2). In this example, each frame line is formed of at least 1280 pixels (or 3840 sub-pixels) therefore requiring 3840 data latches be used to store a single frame line of video data within the line period τ. For example, in one embodiment, when the data stream 400 is received at the display interface 230, a group of 3840 data packets (as defined by corresponding packet headers 406) are stored in a memory 236 that can be either a frame memory or a line buffer. It should also be noted, however, that the memory 236 can be bypassed or be absent altogether if a strictly pipelined architecture is desired. In the pipelined architecture, the video source 204 would provide the necessary control signals and configure the data packets appropriately.

Returning to the described embodiment that includes the memory 236, once all 3840 data packets are properly stored in the memory 236 and accounted for, the stored data packets are then forwarded to the LCD column controller 212. The data packets 228 are then forwarded in a point to point fashion (also referred to as a daisy chain style) to the appropriate ones of the data latches 220 at which point each is depacketized such that the appropriate video data (or audio data) is stored in the appropriate data latch within one line period τ. At this point, the video data is ready to drive the appropriate ones of the pixel elements 210 located in the display 202 after processing by corresponding DACs 222. In this way, the number of lines required to provide the appropriate video data to the data latches 220 can be as low as 2 as opposed to approximately 24 in conventional LCD driver architectures.

FIG. 5 shows an embodiment of the invention whereby a digital display unit 500 includes two column drivers 502 and 504 each of which is used to drive pixels in corresponding portions 506 and 508 of a partitioned display 510. By dividing the display 510 into the portions 506 and 508, each of the column drivers 502 and 504 require substantially less current to drive the corresponding picture elements 512 and 514 (which may include, for example, TFTs 218 described earlier) since the parasitic capacitance due to the reduced length of the data lines 516 and 518 are commensurably reduced.

FIG. 6 illustrates a system 600 that can be used to implement the invention. The system 600 is only an example of a graphics system in which the present invention can be implemented. System 600 includes central processing unit (CPU) 610, random access memory (RAM) 620, read only memory (ROM) 625, one or more peripherals 630, graphics controller 660, primary storage devices 640 and 650, and digital display unit 670. CPU 610 is also coupled to one or more input/output devices 690. Graphics controller 660 generates image data and corresponding reference signals, and provides both to digital display unit 670. The image data can be generated, for example, based on pixel data received from CPU 610 or from an external circuitry.

Although only a few embodiments of the present invention have been described, it should be understood that the present invention may be embodied in many other specific forms without departing from the spirit or the scope of the present invention. The present examples are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

While this invention has been described in terms of a preferred embodiment, there are alterations, permutations, and equivalents that fall within the scope of this invention. It should also be noted that there are many alternative ways of implementing both the process and apparatus of the present invention. It is therefore intended that the invention be interpreted as including all such alterations, permutations, and equivalents as fall within the true spirit and scope of the present invention. 

1. A system comprising; a display unit arranged to display video data; and a display unit controller unit operatively coupled to the display unit, wherein the display unit controller enables the display unit to display the video data without any timing adjustments being applied to the video data.
 2. A system as recited in claim 1, wherein the system is in communication with a video source configured to provide the video data.
 3. A system as recited in claim 1, wherein the display unit controller comprises: a plurality of data latches in accordance with a native horizontal line resolution of the display unit.
 4. A system as recited in claim 3, wherein the data latches are connected to each other in a point to point daisy chain configuration.
 5. A system as recited in claim 4, wherein the plurality of data latches is populated with appropriate video data within a line period τ.
 6. A system as recited in claim 2, wherein the system is connected to the video source by way of a link and wherein the video data takes the form of video data packets and wherein the video data packets are passed from the video source directly to the display unit interface over the link at a link rate.
 7. A display controller, comprising: a video display interface arranged to operatively couple the display controller to a display unit; and a video source interface arranged to receive video data from a video source wherein the display controller enables the display unit to display the video data received from the video source without any timing adjustments being applied to the video data.
 8. A display controller as recited in claim 7, wherein the display controller includes a plurality of data latches in accordance with a native horizontal line resolution of the display unit.
 9. A display controller as recited in claim 8, wherein the data latches are connected to each other in a point to point daisy chain configuration.
 10. A display controller as recited in claim 9, wherein the plurality of data latches is populated with appropriate video data within a line period τ.
 11. A display controller as recited in claim 7, wherein the video source interface is connected to the video source by way of a link and wherein the video data takes the form of video data packets and wherein the video data packets are passed from the video source over the link directly to the display controller by way of the video source interface at a link rate.
 12. A display controller as recited in claim 7, wherein the display unit is partitioned into at least two partitions each of which is provided appropriate video data by the display unit interface.
 13. A display controller as recited in claim 12, wherein an amount of current required to display the video data by each of the partitions is substantially reduced over that which would otherwise be required.
 14. A display controller as recited in claim 1, wherein the display unit is a LCD display unit.
 15. A method performed by a video processor operatively coupled to a video display, comprising: receiving video data at the video processor; and the video processor enabling the video display to display the received video data without applying any timing adjustments to the video data.
 16. A method as recited in claim 15, wherein the video data is packetized video data.
 17. A method as recited in claim 16, wherein the video processor includes a display interface operatively coupled to the display unit and a video source interface arranged to receive the video data packets.
 18. A method as recited in claim 17, wherein the received video data packets are forwarded directly to the display interface.
 19. A method as recited in claim 18, display interface includes a plurality of data latches in accordance with a native resolution of the display unit.
 20. A method as recited in claim 19, wherein the plurality of data latches are connected to each other in a daisy chain arrangement.
 21. A method as recited in claim 19, wherein the received video data packets are forwarded directly to the plurality of data latches in a pipelined manner.
 22. A method as recited in claim 15, wherein the video display is partitioned into at least two partitions each of which is provided appropriate video data by the video processor.
 23. A method as recited in claim 22, wherein an amount of current required to display the video data by each of the partitions is substantially reduced over that which would otherwise be required.
 24. A method as recited in claim 15, wherein the video display is a LCD display unit. 